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DETAILED ACTION 
Remarks 

1. In response to communications filed on 21-July-2005, claims 1-45 are amended per 
applicant's request. Claims 1-45 are presently pending in the application. 

Continued Examination Under 37 CFR LI 14 

2. A request for continued examination under 37 CFR 1.114, including the fee set forth in 
37 CFR 1 .17(e), was filed in this application after final rejection. Since this application is 
eligible for continued examination under 37 CFR 1.1 14, and the fee set forth in 37 CFR 1.17(e) 
has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 
37 CFR 1.1 14. Applicant's submission filed on 21-July-2005 has been entered. 

Drawings 

3. The examiner acknowledges that no objections to the drawings are (or have been) made. 
A final review of the drawings will be made in the future before the mailing of any Notice of 
Allowance. If the applicant becomes aware of any errors in the drawings during the course of 
prosecution of the case, the applicant is asked to submit corrections of these errors. 

Claim Rejections - 35 USC § 112 

4. The following is a quotation of the second paragraph of 35 U.S.C 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 
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5. Claims 7-8, 20-21, and 34-35 are rejected under 35 U.S.C. 1 12, second paragraph, as 
being indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. 

Claims 7-8, 20-21, and 34-35 each recite the limitation "the determined remote storage 
location". There is insufficient antecedent basis for this limitation in the claims. 

Claim Rejections - 35 USC § 103 

6. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

7. Claims 1-5, 9-18, 22-31, and 35-45 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Xu et al. (U.S. patent No. 6,324,581 Bl) in view of Nahum (U.S. patent No. 
6,898,670 B2). 

As to claim 1, Xu et al. teaches a method for controlling and providing access to files 
maintained at remote storage locations to a source code management system client over a 
network, the method comprising: 

receiving a request, at a server, for checking-out a file corresponding to a filename, from 
the source code management system client over the network (see column 10, lines 12-14, where 
it is obvious that a request would include the filename); 
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determining from the metadata, by the server, a remote storage location address 
associated with the filename where the requested file is located, wherein the remote storage 
location address is based on a history of request patterns from a plurality of source code 
management system clients (see column 10, lines 14-17, where "history of request patterns" is 
interpreted as the location the file has been during previous requests); 

sending, by the server, the remote storage location address to the source code 
management system client (see column 10, lines 14-19); and 

updating, by the server, the metadata to indicate that the requested file is checked-out and 
locked (see column 10, lines 14-25). 

Xu et al. does not teach 

(a) wherein the metadata corresponds to the files and is stored more proximate to the 
server than to the source code management system client , 

(b) wherein the one remote storage location address where the requested file is located is 
more proximate to the source code management system client than to the server 

Nahum teaches (a) and (b), see figure 17, reference numbers 1, 4, 5, 6, 1R, and 80; see 
column 9, lines 31-35; and see column 19, lines 52 through column 20, line 18. Therefore, it 
would have been obvious for one of ordinary skill in the art at the time the invention was made 
to have modified Xu et al. to include the teachings of Nahum because they would permit many 
SANs to be managed remotely and simultaneously (see column 20, lines 14-18). 
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As to claims 2, 15, and 28, Xu et al. as modified, teaches wherein the source code 
management system client and the remote storage location address share a subnet of the network 
(see Nahum, figure 17, reference numbers 1, 2, 4, and 5). 

As to claims 3, 16, and 29, Xu et al as modified, teaches wherein the one remote storage 
location address identifies a storage device that is at a geographical location closer to the source 
code management system client than a location of the metadata (see Nahum , figure 17, reference 
numbers 1, 2, 4, and 5), and wherein based on the received request the server that received the 
request for checking out the file from the source code management system client directly 
communicates the remote storage location address for retrieval of the requested file to the 
network for transmission to the source code management system client (see Xu et al. , column 10, 
lines 14-19) . 

As to claims 4, 17, and 30, Xu et al. as modified, teaches the method further comprising: 
locking the requested file; returning a response code to the source code management system 
client indicating that file check-out is successful (see Xu et al , column 9, lines 59 through 
column 10, line 25). 

As to claims 5, 18, and 31, Xu et al. as modified, teaches wherein the request is a first 
request wherein the file for checking-out is a first file, wherein the response code is a first 
response code and where a second request is for checking-in a second file, the method further 
comprising: updating the metadata indicating the requested send file is unlocked; and returning a 



Application/Control Number: 10/038,165 Page 6 

Art Unit: 2164 

second response code indicating that the check-in of the second file is successful (see Xu et aL 
column 10, lines 17-25). 

As to claims 9, 22, and 35, Xu et al. as modified, teaches the method further comprising: 
receiving an additional request corresponding to an additional file; updating the metadata 
and sending a response code to the source code management system client in response to 
determining that the additional request is one of a lock, an unlock, or a delete request; updating 
the metadata and sending location of the additional file and the response code to the source code 
management system client is response to determining that the additional request is one of a 
check-in or an extract request (see Xu et al. , column 10, lines 12-17). 

As to claim 10, Xu et al. teaches a method for accessing a file in a source code 
management system, the method comprising: 

sending, from a source code management system client, a first request for checking-out 
the file to a server (see column 10, lines 12-14); 

receiving, at the source code management system client, a storage location address 
containing the file in response to the first request, and wherein the storage location has been 
determined from the metadata by the server based on a history of request patterns from a 
plurality of source code management system clients (see column 10, lines 14-19); 

sending, from the source code management system client, a second request to the storage 
location address (see column 10-lines 17-19); and 
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receiving, at the source code management system client, an access to the file from the 
storage location address, wherein the server updates the metadata to indicate that the file is 
checked-out and locked after providing the access (see column 10, lines 19-22). 

Xu et al. does not teach: 

(a) wherein the storage location address containing the file is located more proximate to 
the source code management system client than to the server; 

(b) wherein metadata corresponding to the file is kept more proximate to the server than 
to the source code management system client. 

Nahum teaches (a) and (b), see figure 17, reference numbers 1, 4, 5, 6, 1R, and 80; see 
column 9, lines 31-35; and see column 19, lines 52 through column 20, line 18. Therefore, it 
would have been obvious for one of ordinary skill in the art at the time the invention was made 
to have modified Xu et al. to include the teachings of Nahum because they would permit many 
SANs to be managed remotely and simultaneously (see column 20, lines 14-18). 

As to claims 1 1, 24, and 37, Xu et al. as modified, teaches the method further comprising: 
downloading the file from the storage location address (see Xu et al. , column 10, lines 17-19). 

As to claims 12, 25, and 38, Xu et al. as modified, teaches wherein a third request is for 
checking-in the file, the method further comprising: sending a new version of the fide to the 
storage location address during the checking-in of the file (see Xu et al. , column 10, lines 19-25). 

As to claims 13, 26, and 39, Xu et al. as modified, teaches the method further comprising: 
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receiving a first response code from the server in response to the first request (see Xu et 
aL, column 10, lines 14-19); and 

receiving a second response code from the storage location in response to the second 
request (see Xu et aL column 10, lines 17-19); and 

receiving a third response code from the server in response to the third request (see Xu et 
aL, column 10, lines 14-19). 

As to claim 14, Xu et al. teaches system for controlling and providing access to a file to 
source code management system clients over a network, wherein remote storage locations are 
accessible over the network, the system comprising: 

means for receiving a request for checking-out a file corresponding to a filename, from a 
source code management system client over the network (see column 10, lines 12-14); 

means for determining from the metadata a storage location address of a remote storage 
location associated with the filename where the requested file is located wherein the metadata 
corresponds to the files and wherein the remote storage location address is based on a history of 
request patterns from a plurality of source code management system clients (see column 10, lines 
14-17); 

means for sending the remote storage location address to the source code management 
system client (see column 10, lines 14-19); and 

means for updating the metadata to indicate that the requested file is checked-out and 
locked (see column 10, lines 14-25). 

Xu et al. does not teach: 
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(a) is stored more proximate to the system than to the source code management system 
client, and 

(b) wherein the remote storage location address where the requested file is located is 
more proximate to the source code management system client than to the system. 

Nahum teaches (a) and (b), see figure 17, reference numbers 1, 4, 5, 6, 1R, and 80; see 
column 9, lines 31-35; and see column 19, lines 52 through column 20, line 18. Therefore, it 
would have been obvious for one of ordinary skill in the art at the time the invention was made 
to have modified Xu et al. to include the teachings of Nahum because they would permit many 
SANs to be managed remotely and simultaneously (see column 20, lines 14-18). 

As to claim 23, Xu et al. teaches a system for accessing a file in a source code 
management system, wherein the system is in communication with a server, the system 
comprising: 

means for sending a first request for checking-out the file to the server (see column 10, 
lines 12-14); 

means for receiving a storage location address containing the tile in response to the first 
request, and wherein the storage location has been determined from the metadata by the server 
based on a history of request patterns from a plurality of source code management system clients 
(see column 10, lines 14-19); 

means for sending a second request to the storage location address (see column 10, lines 
17-19); and 
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means for receiving at, access to the file from the storage location address wherein the 
server updates the metadata to indicated that the file is checked-out and locked after providing 
the access (see column 10, lines 19-22). 

Xu et aj does not teach: 

(a) wherein the storage location address containing the file is located more proximate to 
the system than to the server, and 

(b) wherein metadata corresponding to the file is kept more proximate to the server than 
to the system. 

Nahum teaches (a) and (b), see figure 17, reference numbers 1, 4, 5, 6, 1R, and 80; see 

I 

column 9, lines 31-35; and see column 19, lines 52 through column 20, line 18. Therefore, it 
would have been obvious for one of ordinary skill in the art at the time the invention was made 
to have modified Xu et al. to include the teachings of Nahum because they would permit many 
SANs to be managed remotely and simultaneously (see column 20, lines 14-18). 

As to claim 27, Xu et al. teaches an article of manufacture including code for controlling 
and providing access to files at storage locations on a network to a source code management 
system client coupled to a server over the network, wherein the code is capable of causing 
operations, the operations comprising: 

receiving a request, at the server, for checking-out a file corresponding to a filename from 
the source code management system client over the network (see column 10, lines 12-14); 

determining from the metadata, by the server, a remote storage location address 
associated with the filename where the requested file is located, wherein the remote storage 
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location address is based on a history of request patterns from a plurality of source code 
management system clients (see column 10, lines 14-17); 

sending, by the server, the remote storage location address to the source code 
management system client (see column 10, lines 14-19); and 

updating, by the server, the metadata to indicate that the requested file is checked-out and 
locked (see column 10, lines 14-25). 

Xu et al. does not teach: 

(a) wherein the metadata corresponds to the files and is stored more proximate to the 
server than to the source code management system client, and 

(b) wherein the remote storage location address where the requested file is located is 
more proximate to the remote-computer source code management system client than to the 
server. 

Nahum teaches (a) and (b), see figure 17, reference numbers 1, 4, 5, 6, 1R, and 80; see 
column 9, lines 31-35; and see column 19, lines 52 through column 20, line 18. Therefore, it 
would have been obvious for one of ordinary skill in the art at the time the invention was made 
to have modified Xu et al. to include the teachings of Nahum because they would permit many 
SANs to be managed remotely and simultaneously (see column 20, lines 14-18). 

As to claim 36, Xu et al. teaches an article of manufacture including code for accessing a 
file in a source code management system from a source code management system client to a 
server, wherein the code is capable of causing operations, the operations comprising: 
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sending, from the source code management system client, a first request for checking-out 
the file to the server (see column 10, lines 12-14); 

receiving, at the source code management system client, a storage location address 
containing the file in response to the first request, and wherein the storage location has been 
determined from the metadata by the server based on a history of request patterns from a 
plurality of source code management system clients (see column 10, lines 14-19); 

sending, from the source code management system client, a second request to the storage 
location address (see column 10, lines 17-19); and 

receiving, at the source code management system client, an access to the file from the 
storage location address, wherein the server updates the metadata to indicated the file is checked- 
out and locked after providing the access (see column 10, lines 19-22). 

Xu et al. does not teach: 

(a) wherein the storage location address containing the file is located more proximate to 
the source code management system client than to the server, and 

(b) wherein metadata corresponding to the file is kept more proximate to the server than 
to the source code management system client. 

Nahum teaches (a) and (b), see figure 17, reference numbers 1, 4, 5, 6, 1R, and 80; see 
column 9, lines 31-35; and see column 19, lines 52 through column 20, line 18. Therefore, it 
would have been obvious for one of ordinary skill in the art at the time the invention was made 
to have modified Xu et al. to include the teachings of Nahum because they would permit many 
SANs to be managed remotely and simultaneously (see column 20, lines 14-18). 
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As to claims 40, 42, and 44, Xu et al. as modified, teaches wherein the source code 
management system client is a first source code management system client, wherein the first 
source code management system client and a second source code management system client are 
included in, the plurality of source code management system clients, wherein the first source 
code management system client is in a first subset of the network, wherein the second source 
code management system client is in a second subnet of the network, wherein the remote storage 
location address sent by the server is in the first subnet of the network (see Nahum, column 20, 
lines 14-18), the method further comprising: 

sending, by the server, an additional remote storage location address that is in the second 
subnet to the second source code management system client, in response to an additional request 
from the second source code management system client for checking-out an additional file (see 
Xu et al. column 10, lines 19-22). 

As to claims 41, 43, and 45, Xu et al. as modified, teaches wherein the source code 
management system client is a first source cede management system client, wherein the first 
source code management system client and a second source code management system client are 
included in the plurality of source code management system clients, wherein the source code 
management system client is in a first subnet of the network, wherein the second source code 
management system client is in a second subnet of the network, wherein the remote store 
location address received at the first source code management system client is in the first subnet 
tithe network (see Nahum , column 20, lines 14-18), the method further comprising: 
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sending, from the second source code management system client, an additional request 
for checking out an additional file to the server (see Xu et aL (see column 10, lines 17-19)); and 

receiving, at the second source code management system client, an additional remote 
storage location address that is in the second subnet (see Xu et aL , column 10, lines 19-22). 

8. Claims 6-8, 19-21, and 32-34 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Xu et al. (U.S. patent No. 6,324,581 Bl) in view of Nahum (U.S. patent No. 6,898,670 B2) 
as applied to claims 1-5, 9-18, 22-31, and 35-45 above, and further in view of Porcar ("File 
Migration in Distributed Computer Systems", California Univ., Berkeley. Lawrence, Berkeley 
Lab, copyright© 1982). 

As to claims 6, 19, and 32, Xu et al. as modified, does not teach wherein a table 
maintains statistics for file usage, the method further comprising: 

(a) processing a pattern of requests for the requested file received from source code 
management system clients at different geographical locations; 

(b) determining from the table a plurality of remote storage locations based on the pattern 
of requests for the requested file; 

(c) storing the requested file corresponding to the filename at the determined plurality of 
remote storage locations; and 

(d) saving a correspondence between the requested file and storage location addresses 
corresponding to the determined plurality of remote storage locations in the metadata. 

Porcar teaches (a) and (b), see section 5.2. The Migration Policies; and (c) and (d), see 
section 5.3. Experimental Results. Therefore it would have been obvious for a person of 
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ordinary skill in the art at the time the invention was made to have modified Xu et al. to include 
the teachings of Porcar because the teachings would reduce the traffic an order of magnitude as 
compared to single-copy policies (see Porcar , 5.4. Conclusions). 

As to claims 7, 20, and 33, Xu et al. as modified, teaches wherein the determined remote 
storage location is at a geographical location that is more proximate to the source code 
management system client having more requests for the requested file than other source code 
management system clients (see Porcar . section 5.1.1.6. Distributing the Updates). 

As to claims 8, 21, and 34, Xu et al. as modified, teaches wherein the determined remote 
storage location is selected from the plurality of remote storage locations to minimize a distance 
the requested file is transmitted between each source code management system client and the 
determined remote storage location based on the number of requests for the file from each source 
code management system client (see Porcar . section 5.2. Migration Process). 

Response to Arguments 
9. Applicant's arguments with respect to claims 1-45 have been considered but are moot in 
view of the new ground(s) of rejection. 



Conclusion 
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10. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Jacob F. Betit whose telephone number is (571) 272-4075. The 
examiner can normally be reached on Monday through Friday 9 am to 5 pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Charles Rones can be reached on (571) 272-4085. The fax phone number for the 
organization where this application or proceeding is assigned is 703-872-9306. 



jfb 
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SAM RIMELL 
""^RY EXAMINER 



